home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14247 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.0 KB  |  59 lines
  1. Newsgroups: comp.lang.ada,comp.lang.c++
  2. Path: netcom.com!wnewman
  3. From: wnewman@netcom.com (Bill Newman)
  4. Subject: Re: some questions re. Ada/GNAT from a C++/GCC user
  5. Message-ID: <wnewmanDp18w0.L3@netcom.com>
  6. Followup-To: comp.lang.ada,comp.lang.c++
  7. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  8. X-Newsreader: TIN [version 1.2 PL1]
  9. References: <wnewmanDoxrCp.DKv@netcom.com> <leschkes.828053356@ferret>
  10. Date: Fri, 29 Mar 1996 14:14:24 GMT
  11. Sender: wnewman@netcom20.netcom.com
  12.  
  13. Scott Leschke (leschkes@ferret.cig.mot.com) wrote:
  14. : wnewman@netcom.com (Bill Newman) writes:
  15.  
  16. : >When I make two different instantiations of a generic package with the
  17. : >same arguments, I understand the compiler treats them formally as two
  18. : >different packages, which is OK with me.  However, I'd appreciate
  19. : >knowing the compiler wouldn't actually output two redundant copies of
  20. : >the corresponding (identical?) machine code, but instead share the
  21. : >code.  I saw somewhere that the compiler is given considerable freedom
  22. : >to share one instantiation between several arguments if it thinks it's
  23. : >appropriate, which is also OK with me.  However, I haven't seen any
  24. : >guarantee that the compiler won't output redundant copies for
  25. : >instantiations with identical arguments.  Is there such a guarantee?
  26.  
  27. : My first question would be, why do you want redundant instantiations.
  28. : Note that Ada separates instantiation of a generic from use of the
  29. : resulting package/subunit.  The general rule of thumb to avoid code-bloat
  30. : due to duplicate instantiations is to do the instantiation at the library
  31. : level and 'with' the resulting package/subunit.
  32.  
  33. I wondered about this because Ada encourages the creation of type
  34. distinctions which don't reflect differences in underlying machine
  35. representation.  In seems as though (mixing C++ template notation with
  36. Ada's distinct types represented by machine floating point numbers)
  37. Dynamically_Allocated_Stack_Of<Apple_Juice_Volume> and
  38. Dynamically_Allocated_Stack_Of<Orange_Juice_Volume> could share
  39. exactly the same underlying code.  It would be nice if the compiler
  40. would recognize this without me having to figure out some way to
  41. implement the templates/generics to make it explicit.  Even in C++
  42. (without the option of conveniently making distinct Apples and Oranges
  43. types out of e.g. float) this comes up frequently when you use
  44. template containers of pointers to things: to the machine, a pointer
  45. is a pointer, so the object code tends to be the same regardless of
  46. the pointer type.  Sometimes in C++ I use a shared implementation for
  47. such templates (using void* pointers, and the equivalent of Ada
  48. Unchecked_Type_Conversion (?)) but even though the final result can be
  49. type-safe if done correctly, it's tedious to make sure that it is, and
  50. I'd rather not have to do it in Ada, especially since Ada strongly
  51. discourages this sort of thing.  If the Ada type system multiplies the
  52. number of cases where this would be useful, and if Ada discourages me
  53. from doing it for myself, it would be nice if the Ada compiler would
  54. do it for me.
  55.  
  56.   Bill Newman
  57.   wnewman@netcom.com
  58.  
  59.